Fix pxToBp and bpToPx calculations when there are many displayed regions #3086
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was seeing some small continued inaccuracies in rubberband zooming after looking at #3085
I found that the pxToBp function itself was inaccurate though by hovering over the scalebar and seeing it reporting the wrong coordinate. This adds a fix specifically by looking at all the staticblocks to account for interregionpaddingblocks rather than just interregionpaddingblocks that were on the screen (the previous technique, which notably was not conceptually accurate or implemented correctly)
This pxToBp fix aids proper zooming because the pxToBp coordinates left/right offsets are passed to the rubberband zoom function (moveTo(leftOffset,rightOffset)), so improving pxToBp fixes rubberband zoom also. Has improvements that also flow to other routines that use bpToPx and pxToBp (e.g. synteny uses bpToPx to plot a specific polygon, in bp coordinates, to screen px coordinates)
before, hovering over 4MB shows ~4.7MB
after, hovering over 4MB shows ~4MB